Complex database systems are increasingly important in many aspects of daily life. Such databases contain growing amounts of private or trade secret information. Confidential information such as medical records, bank records, brokerage account records, legal documents, product plans, and prices, for instance are stored in or accessed through various types of databases. Such information should only be viewed and/or modified by appropriate people. Accordingly, it would be helpful to make database security controls relatively easy to implement accurately.
Databases are sometimes used in complex computer networks by directory service providers. Directory services are sometimes called "naming services". Directory service databases that are hierarchical are known as "directory service databases" or "directory service repositories".
Directory service databases are built using a set of rules, called a "schema", which describe the various types of objects in the database and the possible relationships between objects and attributes. The objects are grouped into object classes according to object type. Specific object classes might include "printer", "server", and "user". The object classes have attributes associated with them. Typical attributes for the user class are "group membership", "account balance" and "telephone number". Finally, objects also have attributes. These attributes are individual instantiations of the class attributes, such as a specific account balance or telephone number.
In some hierarchical databases, objects may also be grouped in containers. A particular container object serves as the root of a particular subtree. One use of subtrees is to control access to objects in the database, as discussed below.
Databases use various approaches to control access to objects and attributes, including access control lists, inherited rights filters, and security equivalences. Commonly owned application Ser. No. 08/821,087 filed Mar. 20, 1997 and entitled "Controlling Access to Objects in a Hierarchical Database" ("the '087 application"), now U.S. Pat. No. 5,878,415 discusses an invention which provides inheritable access constraints such as object class filters and inheritance constraints on specific object properties. The '087 application is herein incorporated by reference. Access control is also discussed at pages 389-401 of NetWare 4 for Professionals, ISBN 1-56205-217-9 ("NetWare 4"), incorporated herein. The terms "attribute" and "property" are used interchangeably in NetWare 4 and herein, as are the terms "attribute syntax" and "property syntax". For convenience, aspects of those discussions of access control tools are repeated here.
An access control list ("ACL") is an optional property of every object class. In some implementations, every object in the database can have an ACL. Multiple ACLs may exist on a single object, and there is no limit (other than space and efficiency considerations) on the number of ACLs per object. The ACLs of a target object identify specific trustees, namely, objects that are given rights to access the target object and/or properties of the target object. In short, each ACL on a target object normally grants at least one access right to at least one trustee whose identity is specified in the ACL.
In some implementations, each ACL has three parts. The first part identifies the trustee object receiving the access rights. This is done by an object ID, GUID, tuned name, distinguished name, or other object identifier which presently identifies a particular object. In some cases, the position normally occupied by the object ID holds instead a special value which indicates that an inherited rights filter is present.
The second part of the ACL identifies a property type, thereby indicating the property or properties for which the access rights are being given. Property types might include "object rights", "all properties rights", and specific properties, for instance. This part of the ACL indicates the level at which the right is being granted. For instance, "object rights" indicates rights are being granted to the object itself, while "all properties rights" indicates rights are being granted to the properties of the object. Inherited rights filters and inheritance of specific properties are discussed in the '087 application; that discussion is incorporated here by reference.
The third part of the ACL identifies at least one access right that is given to the trustee object for properties of the indicated property type. For "object rights", possible access rights might include rights to browse, create, delete, rename, or supervise. For "all properties rights", possible access rights could include rights to compare, read, write, add or delete self, or supervise.
In some systems, rights granted to "object rights" or "all properties rights" may be inherited. For instance, rights granted at a container may also apply to all objects in the subtree of which the container is the root.
It is often desirable to grant rights suitable for administration of particular resources. For instance, a printer administrator would need rights to add, delete, and modify printer objects in a subtree. A telephone number administrator would need rights to modify telephone numbers or user objects. A password administrator would need rights to change a user's password when the user forgets the original password. And, a personnel administrator would need rights to create, modify, delete, and move user objects to reflect personnel changes. Most (or all) users need to be granted access to modify their own files, and change their own personal information, such as their telephone numbers and their addresses. It is desirable to grant these specialized administration rights in a way that is compatible with existing access control mechanisms, so that the database is not taken out of service during a long and painful conversion process.
One conventional approach is to give each of these specialized administrators supervisor rights to the appropriate subtree(s). Unfortunately, this often gives specialized administrators more rights than are strictly necessary. Furthermore it cannot be practically used when giving individual rights to users. Granting excess rights may lead at best to inconsistent attempts to change the database, as when a user changes a phone number and an administrator inadvertently loses the update by restoring data from an old backup. At worst, excess rights may lead to a security breach which compromises the secrecy and the integrity of information in the database.
Another approach is to place an appropriate ACL on each administered object. However, rather than easing administration, this creates significant maintenance burdens. The number of objects involved is often large, and updating the ACLs in a large subtree can be time-consuming, tedious, and error-prone.
Thus, it would be an advancement in the art to provide improved ways to efficiently grant limited rights to specialized administrators and users in a database.
It would be an additional advancement to provide improvements which extend the capabilities of existing access control mechanisms, and hence can be used in conjunction with existing mechanisms.
Such improvements are disclosed and claimed herein.